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ABSTRACT 


Airborne Mine Countermeasures (AMCM) Command Control Commimication 
Computer and Intelligence (C''I) baseline currently consists of stand-alone tactical 
decision aids. Information such as aircraft position, equipment status, and abbreviated 
mine-like contact reports cannot be transferred in any form other than voice from/to the 
MH-53E helicopters while conducting Airborne Mine Countermeasures operations. 

There are currently no methods to transfer sonar video or single-frame imagery of mine¬ 
like objects between any Mine Warfare (MIW) units in a near-real-time maimer. Delays 
lasting several hours are frequently encountered before the results of a "rapid 
reconnaissance" airborne minehunting mission are made available to the rest of the 
fleet and/or MIW community. In order to improve command and control, the 
AMCM Mine Warfare community must integrate all of its C'^I assets onto a tactical 
internet. 

This thesis presents a tactical internet for AMCM with an open, standards- 
based modular architecture. It is based on the TCP/IP network model using 
common protocols and interfaces. Command and control will significantly 
improve as this network will provide a methodology to transfer critical information 
between AMCM C'*! assets and tactical networks world-wide. Results from a 
comprehensive laboratory prototype demonstration using commercial off-the-shelf 
(COTS) equipment are presented along with lessons learned. Laboratory results 
show that this system works and can be deployed for testing at sea. 
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I. INTRODUCTION 


A. OVERVIEW 

The Helicopter Mine Countermeasures Squadron (HM) Commander 
currently has no method to automatically monitor airborne mine countermeasures 
(AMCM) mission performance, track aircraft position, or to relay time-critical 
information between the AMCM MH-53E helicopter assets and the HM 
Squadron's Mobile Operations Center (MOC). Often there is a two-to-four hour 
delay before any information from post-mission analysis (PMA) is forwarded from 
the HM Squadron's MOC to the MCM Commander via standardized message 
formats. This delay is tactically unacceptable as it undermines the basic premise 
of using AMCM assets for rapid reconnaissance in that it is not rapid. 

As a result of this lack of capability, operational command and control is 
not optimized and rests on voice communications for data transfer. Non¬ 
development-item (NDI) and commercial-off-the-shelf (COTS) equipment and 
software is available today which, when coupled in a coherent architecture with 
existing MH-53E AMCM systems, can: 

• Automatically monitor mission performance 

• Provide flight following and track AMCM asset positions 

• Be used to report mine-like contact locations 

• Process real-time full-motion sonar video, and 

• Provide near-real time single frame sonar imagery. 
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This system provides near-real time mission analysis, improves command 
and control, and the enhances the overall effectiveness of the AMCM assets. Thus 
a great improvement in MH-53E AMCM capabilities is technically feasible. 

B. PURPOSE OF RESEARCH 

The purpose of this thesis is to identify an AMCM Cl Information System 
architecture which will provide complete connectivity between all airborne and 
ship and/or shore based AMCM C'^I assets. This system will lay an interoper¬ 
ability foundation - both within the MIW community, and externally, with the 
Navy and other Joint components. High levels of availability, scalability, 
compatibility, and flexibility will be achieved as a result of the information 
system’s network based architecture. The design limits risk and complexity by 
using open standards as common interfaces between modular system components, 
regardless of whether those components are development items or not, and thus 
provides an evolvable baseline. 

This thesis will outline the technical feasibility of a internetworked Internet 
Protocol (IP) compatible AMCM C*! Information System using commercial-off- 
the-shelf (COTS) and non-development item (NDI) equipment available today. 
This thesis also reports initial proof-of-concept testing over radio frequency (RF) 
environments. Numerous configuration options are available as the individual 
components within the system can be interchanged easily within the modular 
architecture. The AMCM C'*! Information System outlined in this thesis is capable 
of automatically monitoring the performance of AMCM assets, transferring mine¬ 
like object position information, and providing real-time sonar video and mine-like 
object imagery from Navy MH-53E helicopters to the MOC in ranges up to and 
including over-the-horizon. The system will enable real-time computer-aided 
mine-like object detection and eliminate unnecessary delays in processing critical 
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time-sensitive information. This system also provides avenues for further addition 
of automatic target recognition processes to the airborne sensor. In summary, the 
purpose of the AMCM Information System is to provide complete connectivity 
between airborne and ship/shore based AMCM C'^I assets. 

C. SCOPE OF RESEARCH 

This research presents the requirements, architectural design, initial 
integration and a proof-of-concept demonstration of an experimental prototype 
AMCM C'*! Information System. A laboratory demonstration shows the 
conceptual as well as technical viability of the concepts presented within this 
paper. The initial proof-of-concept demonstration sets the stage for further testing 
and evaluation of the airborne operational data link design that is presented in this 
thesis. This thesis examines the following research questions: 

1. What are the requirements of an AMCM C‘*I Information System? 

2. What is the appropriate system architecture for the AMCM C'*! 
Information System? 

3. How can the AMCM C'*! Information System be used effectively 
during AMCM operations? 

4. What are some effective systems engineering tradeoffs between 
existing technology and operational requirements? 

5. How can the AMCM C"! Information System be used to transfer 
video/imagery data? 

6. How will technology currently under development impact AMCM 
C'^I Information System? 

7. Is it possible to demonstrate a simple working prototype? 

This thesis provides answers to all of these questions. 
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D. LIMITATIONS 


All of the equipment used for the proof-of-concept demonstration was 
loaned by vendors. As a result, some of the equipment is not exactly the same as 
the equipment which is specified for use in the final airborne configuration. 
Further, the lab experience shows that some equipment is mismodularized and has 
the wrong interfaces. Specifically, these interfaces are limited to serial connec¬ 
tions only since the desired local-area network (LAN) interfaces were not 
provided. As a result, several different kinds of serial-to-LAN connections had to 
be used. However, the overall architecture remains consistent as both versions 
comply with the architectural standards described within this thesis. Additionally 
the sonar imagery from the sensor itself is simulated by using a VHS video 
cassette tape of sonar sensor data as the input data source. 

Finally, the unexpected termination of orders and equipment to complete 
this project precluded a fully planned end-to-end demonstration test at sea using 
MH-53E assets. This unfortunate decision has precluded rapid testing and deploy¬ 
ment of a working system to fleet mine-hunting helicopters that lack the connec¬ 
tivity needed to properly perform their assigned mission. 

Round-the-clock effort was able to record the knowledge gained in this 
thesis in the two weeks permitted between change of orders and graduation. The 
author and advisors remain optimistic that these setbacks are temporary and the 
solutions provided in this thesis may yet be reimplemented. Fleet need for such 
solutions is clearly critical. 

E. THESIS ORGANIZATION 

The thesis is organized as follows: Chapter II defines the problem state¬ 
ment. Chapter III describes AMCM C*! Information System Architecture, which 
provides the big picture of the overall solution. Chapter IV presents the AMCM 
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Tactical Internet. Chapter V describes the common networking interfaces. 
Chapter VI describes the requirements perspective and outlines the systems 
engineering trade-offs necessary to achieve near-real time results. Chapter VTI 
discusses the related work and the current relationship with the AMCM C'^I 
Information System. Chapter VIII presents the recommendations for future work. 
Chapter IX presents the demonstration results. Chapter X presents the lessons 
learned and conclusions. 
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11. PROBLEM STATEMENT 


A. INTRODUCTION 

This chapter defines the AMCM MH-53E command and control problem 
and provides a baseline assessment of current AMCM C'^I systems. 

B. COMMAND AND CONTROL PROBLEM 

The ability to make sound and timely decisions is the key objective of the 
command and control process. 

The defining features of command and control problem - uncertainty 
and time - exert a significant influence on decision making. As 
knowledge about a situation increases, our ability to make an appro¬ 
priate decision also increases. [Ref. 1 :p. 24] 

In amphibious, expeditionary, and littoral warfare operations, the mine 
warfare tactical picture is a critieal component of the overall tactical picture. Each 
group commander needs an accurate and timely view of where he can and cannot 
safely sail. The AMCM component of the MIW forces is a critical component to 
this tactical picture. 

Proper command and control improves a commander’s situational aware¬ 
ness. Proper command and control enables the commander to understand a 
situation, select a course of action, issue directives, monitor on-going operations 
and effectively evaluate the results. Proper command and control also maximizes 
search effectiveness and minimizes the risks of mine detonation against friendly 
shipping. 
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1. MIW Community 

Command and Control is significantly impaired in the MIW community due 
to the lack of a community-wide, fully integrated C^I system that is also fully 
interoperable with the larger group commander’s C'^I system. Communications 
coimectivity must extend to the individual asset level for Mine Warfare (MIW) 
command and control to be optimized. For example, information such as asset 
position, status, etc. is essential to enable timely and tactically efficient deconflie- 
tion between MIW assets. 

2. AMCM Community 

The MIW command and control problem is aggravated by the AMCM 
community's lack of a cohesive, interoperable C"! system. AMCM surveillance 
"minehunting" missions have a high percentage of mission time dedicated to 
searching. Invariably multiple units are involved in each operation. However, the 
AMCM assets used in mine-hunting and the surface/EOD based assets used to 
disable/destroy the mine have no means to transfer information other than voice. 
Therefore a considerable amount of time passes between initial detection and 
actual notification of prosecution asset, since multiple information hand-offs are 
required. These hand-offs are further delayed by the time it takes to complete the 
mission (after spotting the contact on the sonar video), helicopter transit time from 
the operating area to the base, transfer of the sonar tape from the helicopter to the 
MOC, review of tape during post-mission analysis, drafting the message to pass 
the information, and finally the time it takes to transfer the message to the 
prosecuting asset itself. 

Therefore, these delays are extensive and operationally significant since the 
AMCM Commander does not have an effective and efficient means to share 
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critical time-sensitive MIW information with MCM, SMCM, MHC, and EOD 
commanders. 

C. BASELINE CAPABILITIES 

The AMCM community’s O'*! baseline currently consists of stand-alone 
tactical decision aids (TDA) such as the Mission Planning System (MPS) and the 
Post-Mission Analysis (PMA) Workstation. Also, Mine Warfare Environmental 
Decision Aids Library (MEDAL), the mine warfare segment to the Joint Maritime 
Command Information System (JMCIS), has not yet been integrated with the MH- 
53E AMCM aircraft to provide position location information (PLI) or mission 
status information from the AMCM helicopter sensors. Information such as 
position, equipment status, and abbreviated mine-like contact reports currently 
cannot be transferred in any form other than voice to or from the airborne MCM 
helicopters while conducting AMCM operations. Voice transfers of data are not 
preferred as they are manpower intensive and error-prone in high-stress environ¬ 
ments. 

There is currently no method to transfer sonar video or single frame 
imagery of mine-like objects between units in a real-time manner. Figure 2.1 
shows the current C'*! communications baseline. The digital sonar data is instead 
converted to video and stored on magnetic digital tapes during AMCM mine¬ 
hunting operations. Sonar operators mark contacts with a joy stick by pressing a 
button as the contacts appear on a waterfall type display screen. The tapes are 
removed from the aircraft upon landing and are reviewed. The marks are reviewed 
and a decision is made whether the mine-like contact is valid and should be 
reported to the Mine Counter-measures Group, which includes the MCM 
Commander, the EOD divers, SMCM assets etc., or be dismissed as a non-mine- 
like object. This process requires several hours to complete following each 
mission. 
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MH-53E 


REVIEWTAPES 
AFTER LANDING 


VOICE 

ONLY 



Figure 2.1. Existing Baseline for Minesweeping Helicopter Connectivity 
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D. BASELINE NAVAL C"I SYSTEM 


Naval C*! systems are "the information systems, equipment, software, and 
infrastructure that enable the commander to exercise authority and direction over 
assigned forces." [Ref l:p. 24] 

Cl systems need to facilitate information flow throughout the force, not 
just up and down the chain of command. They need to be designed from the 
ground up to be part of an architecture that can be easily integrated with other 
operational systems, software, and databases. O'*! systems support the four basic 
functions: [Ref 1] 

• Collecting. The gathering and formatting of data for processing. 

• Processing. Filtering, correlating, fusing, evaluating, and the 
displaying of data to provide overview of situation. 

• Distributing. Forwarding execution or background information to 
appropriate locations for further analysis or use. 

• Protecting. Safeguarding the information from attempts to exploit, 
destroy or corrupt it. 

E. FOCUS FOR SYSTEM DESIGN 

The AMCM C^I assets must be integrated and internetworked so that they 
can be effectively used together. Once assets are properly integrated onto a local- 
area network (LAN), with an overall goal of complete connectivity with other 
MCM MIW £issets, then optimal C^I integration can be achieved. The focus must 
be on building a communications network that interconnects the AMCM C^I assets 
into a cohesive system, which includes both the MOC and any airborne MH-53E. 



The system must use standard data element definitions so that it is widely 
compatible and not limited to any specific decision support system or sensor. 

F. SUMMARY 

The AMCM community needs to fully integrate the AMCM Helicopter 
Squadron’s C'*! assets. This can be realized through the development of an 
integrated Internetworked AMCM C'*I Information System. A great opportunity 
currently exists in the AMCM community to take advantage of a clean slate in 
forming a real-time AMCM C'^I Information System. Architecturally, there are 
virtually no legacy systems to incorporate as minimal compatibility currently 
exists between AMCM C'^I programs such as MEDAL/JMCIS and other programs 
such as the Mission Planning System (MPS). As a result, there are no systems 
which require monumental reconfiguration efforts in order to achieve compati¬ 
bility. Previous attempts at solving the C'*! problems facing AMCM have always 
resulted in the concentration of efforts toward developing a data link to send 
information back fi-om the helicopter to the MOC. Often data links are designed 
that are sensor/hardware specific and cannot be used with other sensors or mission 
systems (stovepipes). They are costly and difficult to upgrade as they are mission 
specific and tend to use proprietary hardware/software configurations. Inevitably, 
the wrong focus has yielded the wrong solution. 

The Airborne Mine Countermeasures (AMCM) community needs a 
communications network that interconnects the AMCM C^I assets into a cohesive 
network, independent of what is to be carried over it. Once connected, data can be 
transported via any method and received at the other end as long as it is in a format 
that is compatible. 
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III. SYSTEMS ARCHITECTURE 


A. INTRODUCTION 

This chapter presents the Internetworked AMCM C^I Information System 
architectural model. It explains the design concepts of the internetworked AMCM 
C'^I Information System architecture. 

B. AMCM C^I ARCHITECTURE 

The Internetworked AMCM C"*! Information System architecture is based 
on a network-centric design that is inherently modular and allows the exploitation 
of open standards and common interfaces. By dividing the problem into two parts 
(the network and modular end systems) the issues can be broken down between; 

1. What is the proper network? 

2. What is the proper design, specification, and configuration of the 
modular end-systems that are to be attached to the network? 

The AMCM C'*! Information System presented in this thesis is composed of 
multiple mobile local-area networks (LAN) interconnected via a radio-based 
wide-area network (WAN). The MH-53E helicopter is first equipped with a 
mobile LAN designed to fit onto a removable pallet. The MOC must also be fitted 
with a LAN. The MH-53E and MOC LANs are then interconnected via a radio 
WAN. Within the modular design of the network, open standards and common 
interfaces will be used to ensure performance and interoperability between the 
component parts on each of the LANs. 
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1. Network-Centric 

The tactical internet is obviously the central focus of a network-centric 
system design. The overall system is composed of sensors and processors attached 
to the network as shown in Figure 3.1. The network-centric approach avoids the 
temptation to build the system around any central component - where failure or 
obsolescence would require replacing the entire system. Instead, the network itself 
is used to eliminate bottlenecks, single points of failure, and serial connectivity. 

2. Modular 

The AMCM C^I Information System has a modular design. The system can 
be divided into sensors, processors and communications modules that are attached 
through open interfaces to the network. Modular architectures are flexible, 
scalable, reliable and have improved performance. 

3. Common Interfaces 

The are numerous ways to interconnect the end systems on a network. 
Interfaces are needed to physically connect end-systems to the network. Protocols 
are required to provide integrated services and to manage components. Data must 
be defined and packaged so that it may delivered and subsequently unpackaged in 
a way it can be used effectively. Common interfaces are required to ensure 
compatibility between end systems so that the data can be wrapped, sent over the 
network, received, 
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Figure 3.1. Network-Centric Approach to Multiplatform Connectivity 
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unwrapped and then used in a satisfactory manner over and over again, all over a 
tactical internet. These common interfaces are shown in Figure 3.2. 


Common Interface: 

Standard Type: 

Common Data Definition 

Data Standard 

Local-Area Network (LAN) Hardware 
Interface 

Network Standard 

Transmission Control Protocol / Internet 
Protocol (TCP/IP) 

Network Standard 

Electronic Mail (E-Mail) Envelope 
Definition 

Network Standard 

Simple Network Management Protocol 
(SNMP) Agents. 

Network Standard 


Figure 3.2. Common Interfaces for Network-Centric Approach 


C. OPEN STANDARDS 

The AMCM C'*! Architecture proposed in this thesis uses open standards. 
Open standards are publicly documented. As a result, they are nonproprietaiy and 
supported by numerous vendors. Open standards promote interoperability between 
products made by other vendors. Open standards also promote competition, which 
reduces costs and improves product quality as vendors compete among each other. 
Finally, open standards encourage growth as components can be readily added 
which are compatible with the current system regardless of the original vendor or 
contractual source. 

D. SUMMARY 

The AMCM O'*! systems architecture has a network centric modular design 
that uses common interfaces and open standards. Other attempted solutions that 


16 
















connect proprietary non-networked systems in serial will continue to fail. A 
networked approach can connect all platforms and equipment in the AMCM 
system. 
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IV. AMCM TACTICAL INTERNET 


A. INTRODUCTION 

A tactical network provides connectivity between the modular sensors, 
processors, and decision support equipment. The AMCM Information System 
proposed here consists of a local-area network (LAN) in each of the MH-53E 
helicopters, LAN in MOC and radio-wide-area network (WAN) to interconnect 
MH-53E-LAN to MOC-LAN. The interconnection of these LAN groups forms an 
internetwork, or what is more commonly referred to as an internet. Such a 
localized internet is not connected to the global Internet. 

B. ROUTER BASED 

The AMCM Tactical Internet is a classical router-based internet as shown is 
Figure 4.1. The AMCM router-based network will consist mainly of point-to- 
point connections between the MH-53E LANs and the MOC LAN. The radio 
communications/cryptological equipment is attached to the network via the 
routers. Routers are devices that interconnect networks that are either WAN or 
LAN. Routers provide intercommunications between networks with multiple 
protocols. [Ref 2] The router examines the network address of each packet. It 
checks the address against its internal tables and determines the best way to send 
the packet to the next router or destination network. Those packets that contain a 
network address different from the originating processor’s address are forwarded 
or "routed" to that network. Routers also have network management, compression, 
and filtering capabilities. Routers can be used to maintain direct control of the 
path the packet takes from sender to receiver. 
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MH-53E LAN 


ROUTER 


RADIO WAN 


ROUTER 



Figure 4.1. Tactical Internet Topology 
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C. MH-53E HELICOPTER LAN 


Internally, the MH-53E helicopter LAN uses an Ethernet (IEEE802.3), 
which is a carrier sense multiple access/collision detection (CSMA/CD) lOBase-T 
network which provides 10 Mbps throughput at the physical layer. An Ethernet 
hub is used to interconnect the end systems and the router as shown in Figure 4.2. 
Scalability is inherent as numerous Ethernet hubs can be attached to each other. 
The MH-53E LAN components will also host a management agent software 
program to communicate with a central management station. The MH-53E LAN 
router/hub components can be mounted on a palletized rack. Therefore the LAN is 
portable and can be removed as required. 

D. MOBILE OPERATIONS CENTER (MOC) LAN 

The MOC LAN uses an Fiber Data Distributed Interchange (FDDI) back¬ 
bone which provides 100 Mbps throughput. Two or more FDDI/ Ethernet hubs are 
attached to the backbone to provide the routers and end systems with easy access 
to the network as shown in Figure 4.3. To ensure the highest levels of avail¬ 
ability, installation of a dual fiber-optic ring network, with dual-attach station 
(DAS) and duplicate sets of router/radio frequency communication equipment are 
recommended. The dual fiber counter-rotating rings allow network self-healing 
after cable or equipment malfunctions. DAS is the attachment of critical equip¬ 
ment via two independent connections to the network. Duplicate router/commun¬ 
ication equipment is recommended to provide redundant communications paths in 
the event of a single system failure. The MOC LAN will also host the Network 
Management Station. Each of the remote LANs will have management agents that 
will be polled and controlled by the management station in the MOC. 
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Figure 4.2. Proposed MH-53E LAN 
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E. RADIO-BASED WAN 


The wireless radio-based WAN environment requires different design and 
protoeol considerations over the standard "wired" LANs internal to the MH-53E 
and MOC. Although network protocols do not care whether fiber, copper, or 
wireless physical media is used to pass information, most network protocols are 
specifically designed for optimal use over wired networks. To ignore the unique 
characteristics of wireless mobile transmissions can lead to the development of a 
network with terrible performance even though it is logically correct. At this time 
there are no widely accepted, reliable, multicast transport layer protocols that can 
be implemented over a wireless radio-based WAN. In order to avoid the 
implementation of a wireless networking catastrophe, which might have resulted 
from using standard cabled network design and protocols, the AMCM radio-based 
WAN is treated as a point-to-point transmission channel until the protocol 
standards for true radio-based WANs are widely implemented. This approach is 
reliable and well understood. 

1. Interim Solution 

As an interim solution, point-to-point AX.25 packet radio-based coimec- 
tions are used to interconnect the MH-53E LANs to the MOC LAN as shown in 
Figure 4.4. AX.25 is a data link layer protocol that is the de facto standard for 
amateur packet radio, used extensively over radio-based networks world-wide 
since the 1970's [Ref. 2]. AX.25 is the data link layer protocol used by the Naval 
Research and Development (NRaD) Battle Force Electronic Mail System currently 
being distributed throughout the navy. Throughput over radio-based networks can 
vary according to the bandwidth allocated to the channel. High Frequency (HF) 
radios with a 3KHz bandwidth commonly support 2400 bps. 
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Figure 4.4. Radio-Based WAN Topology 










2. Growth Path 

Standard networking protocols will continue to be used internally on the 
wired MH-53E and MOC LANS. The transition from standard wired network to 
wireless networking protocols is made within the router. As a result, to upgrade to 
a reliable-multicast set of network/transport protocols requires minimal effort and 
cost as only the portions of software used to connect the routers to each other over 
the radio-based network will have to be changed. Multicast protocols will make 
the radio-WAN much more scalable and robust. To get there, the routers need 
multicast Internet Protocol (IP) and multicast routing protocols such as the multi¬ 
cast version of Open Shortest Path First (M-OSPF) upgrades. The key issue is that 
these upgrades do not affect any of the sensors in the aircraft, the decision support 
processors in the MOC, or the content/format of the data being passed over the 
radio-based WAN itself It simply improves the performance of the WAN by 
providing a reliable multicast-capable network. 

F. SUMMARY 

The AMCM tactical Internet can be implemented today. An overview of 
the router based tactical internet with the modular end systems attached is shown 
in Figure 4.5. 
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Figure 4.5. Proposed AMCM Tactical Internet 
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V. COMMON NETWORKING INTERFACES 


A. INTRODUCTION 

The Internetworked AMCM architecture consists of five common inter¬ 
faces to attach end systems to the tactical internet. These interfaces include: 

• Local-Area Network (LAN) Hardware Interface 

• Transmission Control Protocol / Internet Protocol (TCP/IP) 

• Electronic Mail (E-Mail) Envelope Definition 

• Common Data Definition 

• Simple Network Management Protocol (SNMP) Agent 

By using these interfaces, the AMCM C'^I Information System will be inter¬ 
operable with tactical networks world wide. 

B. LAN HARDWARE INTERFACE 

The local-area network (LAN) hardware interface is used to connect the 
modular components to the LAN. The hardware interface ought to remain 
consistent throughout the overall system as much as possible in each of the LAN 
environments in order to: 

• Provide a high level of interoperability 

• Reduce costs 

• Provide a path to connect upgrades or additional equipment 
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• Leverage technology - eompartmentalize the development items 

(such as the sonar) behind the LAN interface, so that changes to the 
development item will not impact the rest of the network. 

The recommended MH-53E LAN hardware interfaee is the IEEE 802.3, 
lOBase-T Ethernet set of standards to reduce costs and improve interoperability. 
Serial connections such as RS232, RS449, RS530 between components ought to 
be limited and progressively eliminated as these degrade system modularity and 
flexibility. 

A more eomplex LAN is required for the MOC as it will be used to 
communicate with the MH-53E LANs as well as the ship-based or ground-based 
environment where it is physieally located. The MOC LAN will have a multitude 
of potential connections such as phone, fiber. Integrated Services Digital Network 
(ISDN) / Broad Band ISDN, satellite and possibly even other radio connections. 
Therefore, both FDDI and Ethernet hubs are recommended for use to provide 
common LAN hardware connections for the assorted equipment. Such hubs are 
commercially common and inexpensive. 

C. TCP/IP 

The second common interface is the Transmission Control Protocol Internet 
Protocol (TCP/IP) set of protocols common to the commercial Internet. IP is 
introduced in RFC79I [Ref 3] and TCP is introduced in RFC793 [Ref 4]. TCP/IP 
is an open, standards-based network architecture that is divided into layers and 
protocols. 

1. TCP/IP Network Architecture 

Networks are organized as a series of layers to reduce complexity. The 
purpose of each layer is to provide services to the layers that are above it, without 
the upper layer having to manage the details of how the lower layer actually 
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provides the services. Each layer has protocols, i.e. sets of rules that govern how 
the services are provided. These layers and associated protocols are "stacked" on 
top of each other. Each layer passes information to the layer immediately below it 
until the lowest layer (i.e. the physical layer) is reached. There the information is 
put onto a physical medium and transported over the network. The physical 
medium can be wireless, twisted pair, fiber, cable, etc. The TCP/IP network 
architecture is arranged as follows: 


Layer 

Application 

Transport 

Internet 

Physical/data link 


Protocols 

SMTP, MIME, SNMP 

TCP 

IP 

Ethernet (IEEE802.3), FDDI/ AX.25' 


2. Layers and Protocols 

The Physical/data link layer provides the transfer of information from the 
host to the network. The Internet (internetwork) layer permits a host to inject 
packets into any network and have them travel independently to the destination, 
possibly over different networks. The packets may arrive in any order, as they will 
be sorted as required at the receive end. The internetwork layer defines an official 
packet format and protocol called IP (Internet Protocol). The job of the inter¬ 
network layer is to deliver packets where they are supposed to go across multiple 
networks. 


'SMTP is Simple Mail Transfer Protocol (RPC822). MIME is Multimedia Internet 
Mail Extensions. SNMP is Simple Network Management Protocol. 802.3 is the IEEE 
committee that standardizes CSMA/CD LAN protocols. FDDI is Fiber Distributed Data 
Interface, AX.25 is by Amateur Radio Relay League, Newington, CT. 
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The layer above the internetwork layer in the TCP/IP model is the Transport 
layer. This layer allows source and destination hosts to carry on a conversation. 
The Transmission Control Protocol (TCP) is a reliable connection-oriented 
protocol. TCP was specifically designed to provide a reliable end-to-end byte 
stream over an unreliable network, which means it guarantees an in-order, bit 
perfect data transfer from sender to receiver. The sending TCP process takes an 
incoming data stream and divides it into packets and passes them to the inter¬ 
network layer. The receiving computer TCP receives packets from the network 
layer and reassembles the packets into a data stream. TCP adds support to detect 
errors or lost data and to trigger retransmission until the data is correctly and 
completely recovered. TCP also provides flow control to ensure the packets don’t 
arrive faster than the receiver can manage them. All TCP connections are point-to- 
point. TCP does not support multicasting or broadcasting. However, since TCP is 
the most common transport protocol, TCP provides a base which will allow an 
easy upgrade to a reliable multicast transport layer protocol in the future. Numer¬ 
ous protocols are being developed to augment TCP and are designed to be 
compatible with TCP's current design. 

The final layer is the Application Layer. It contains the high-level protocols 
such as Simple Network Management Protocol (SNMP), Simple Mail Transfer 
Protocol (SMTP), Multipurpose Internet Mail Extensions (MIME), and Secure 
Multipurpose Internet Mail Extensions (S/MIME). 

The TCP/IP protocol suite is the de facto standard of the networking world. 
It is robust. It dynamically adjusts routing of packets to accommodate failures in 
the network channels. TCP/IP allows data to pass over very large networks with 
little management. Other network protocols and dissimilar equipment are 
emphatically not recommended. 
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D. ELECTRONIC MAIL DEFINITION 


The third common interface is the e-mail definition. Electronic mail makes 
it possible to easily encapsulate the desired information inside an addressable 
envelope and transport this information to more than one destination. 

1. User Agents and Daemons 

Electronic mail (e-mail) systems normally consist of two subsystems: the 
user agent which enables users to send and read e-mail, and the message transfer 
agent, which move the message from sender to receiver. The e-mail message 
transfer agents (e-mail daemon) are usually pre-installed on a processing platform 
as part of the e-mail system included with the operating system. The message 
transfer agents are daemons responsible for delivering mail through the system, 
transparent to the user. The user agents are typically local programs that act as a 
graphical or command based interface with an e-mail system. Automated user 
agents are also widely available which can assemble data into a complete message 
and forward the message to the e-mail daemon for delivery. 

2. Envelope 

The e-mail envelope contains all the information needed for transporting the 
message including destination address, security, and priority. The enveloping 
information is independent of the content of the message itself. The envelope 
simply encapsulates the message and .provides the necessary routing information 
for the message transfer agents. The message inside the envelope contains the 
header and the body. The header provides control information for the user agent 
and the body contains the contents of the message itself. 

3. SMTP & MIME 

In 1982 the ARPANET e-mail proposals were published as RFC821 (trans¬ 
mission protocol) [Ref. 5] and RFC822 [Ref. 6] (message format) [Ref. 7:p. 644]. 
Both of these have since become the de facto Internet standards. Today, RFC821 
is commonly known as Simple Mail Transfer Protocol (SMTP). E-mail systems 
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have evolved since RFC822 began as basic ASCII text e-mail. Multimedia exten¬ 
sions have been added to support numerous application requirements. RFC 1521 
[Ref. 8] presents the Multipurpose Internet Mail Extensions (MIME). MIME is 
based on the RFC822 format, but adds structure to the message body and defines 
encoding rules for non-ASCII messages such rich text, imagery, or video. There¬ 
fore, MIME messages can be sent using the existing native e-mail programs and 
protocols. All that must be changed are the sending and receiving user agent 
programs which can easily be done at the user level. MIME messages may 
include the following type and subtype as shown in Figure 5.1 [Ref. 7:p. 655]: 


TYPE 

SUBTYPE 

DESCRIPTION 

Text 

Plain 

Unformatted text 


Richtext 

Text including simple formatting commands 

Image 

Gif 

Still picture in Gif format 


JPEG 

Still picture in JPEG format 

Audio 

Basic 

Audible sound 

Video 

MPEG 

Movie in MPEG format 

Application 

Octet-Stream 

An uninterpreted byte sequence 


Postscript 

A printable document in postscript 

Message 

RFC822 

A MIME RFC822 standard message 


Partial 

Message has been split for transmission 


External-body 

Message itself must be fetched over the net 

Multipart 

Mixed 

Independent parts in the specified order 


Alternative 

Same message in different formats 


Parallel 

Parts must be viewed simultaneously 


Digest 

Each part complete RFC822 message 


Figure 5.1. MIME E-mail Message Types and Subtypes Defined in 
RFC1521 
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Since our project goal is to maximize the number of COTS standard e-mail 
processes used in order to minimize the amount of custom software required, we 
can map all the AMCM data needs into these generic formats. MIME protocol 
extensions provide RFC822 common addressable envelopes that may contain text 
based MCMR reports, mine-like contact positions, aircraft; flight-following/ 
position location information (PLI), imagery and even video. 

4. Message Assembly 

Finally some custom software is needed to gather information fi*om various 
sensors and processors located on the MH-53E LAN and send the information to 
the e-mail user agent for assembly inside the body of the message. This informa¬ 
tion may include a JPEG sonar image of a mine-like object, TARLOC position, 
aircraft PLI, time stamp etc. The software processes may be programmed to 
automatically trap information from various sensors/processors at a desired inter¬ 
val or only when tasked to do so by the user. For example, when the sonar console 
operator marks a mine-like contact by pressing the priority write button on the 
sonar console, all applicable information is then trapped and forwarded to the e- 
mail user agent for assembly. The user agent program receives information from 
the various sensors which it then encapsulates with the mine-like object video or 
image (binary large object) file inside the addressable e-mail envelope. The 
message is then constructed using any combination of the following format types 
shown in Figure 5.2. 
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TYPE 

SUBTYPE 

INFORMATION CONTAINED 

Text 

Plain 

GPS: ( Latitude, Longitude, Date, Time, 

Altitude, Heading, Navigational Error) 

A/C: (Identification, Heading, Skew, Mission) 
Sonar: (Type, Speed, Depth, Altitude) 

Contact: (MILC #, Type of Mine, etc.) 
Environmental: (Bottom Conditions, etc.) 

Image 

JPEG 

Sonar imagery (snippet) in JPEG format 

Video 

MPEG 

Sonar video in MPEG format 


External-body 

A Video Segment/ Image/Description of this 
contact can be retrieved if desired. 

Multipart 

Mixed Text, 
Image, etc. 

Plain Text: lat/long, time, A/C ID, MILC# 

Image: JPEG image of MILC 


Figure 5.2. AMCM C**! Information System Message Structure 

Other messages may be constructed as well including reports such as MCMR-12, 
MCMR-16, and Flight Following PLI Report by using the text type. By using the 
External Body subtype, large files (Video/Imagery) do not need to be transferred 
to all recipients. Recipients may be notified where these files are stored (i.e. in 
the MOC) and they may transfer these files securely fi'om the storage site as 
needed as long as they have the proper access. 

5. Secure E-mail 

In addition to using KG-84C to provide link encryption over the radio 
WAN, e-mail may also be encrypted between nodes on each LAN as several 
alternatives can be used to provide e-mail security. If desired, e-mail over the 
radio-based WAN between the MH-53E user agent and the MOC user agent can 
also use these tools to provide data confidentiality and authenticity. There are 
least four competing choices of secure e-mail. These include Pretty Good Privacy 
(PGP), Secure Multipurpose Internet Mail Extensions (S/MIME), MIME Object 
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Security Services (MOSS), Message Security Protocol (MSP) designed for X.400. 
Fortunately, the issue is modular as only the participating e-mail user agent’s are 
affected, none of the sensors or decision support software. Therefore any of these 
secure e-mail methods can be selected with little downside. 

(S/MIME) was recently developed to add privacy, authentication, and 
tamper-proof parameters to MIME (RFC 1521). Prior to S/MIME, no authentica¬ 
tion, confidentiality, or data integrity properties were provided in SMTP, RFC822, 
or MIME. However, S/MIME provides secure communications between disparate 
or even unknown mail platforms. S/MIME is based on RSA Public Key Crypto¬ 
graphy Standards (PKCS) [Ref 9] and provides a digital signature and a digital 
envelope. A digital signature provides authentication and a digital envelope 
encrypts the contents of the message. This ensures message can only be read by 
the intended recipient. The digital envelope uses an adjustable cipher length key 
with an algorithm like DES or RC2. Numerous vendors have adopted this 
standard including Microsoft, Lotus, Netscape and Qualcomm. For example, 
Qualcomm's Eudora Version 3.0 E-mail program added S/MIME to the applica¬ 
tion layer. Mastercard and Visa also use the same PKCS #7 Cryptographic 
Message Syntax standard as well. 

6. X.400 

Two years after RFC821/822 was presented, X.400 appeared as CCITT 
recommendation, which was again modified in 1988. X.400 is based on ASN.l 
encodings, not text like SMTP, RFC822, and MIME. After a decade of competi¬ 
tion, e-mail systems based on RFC822 are widely used, whereas those based on 
X.400 have mostly disappeared (despite this fatal defeat, X.400 is surprisingly 
proposed as the e-mail standard for SPAWARs MIW C^ISR Systems Arehitec- 
ture). Numerous compatibility problems remain between 1984 X.400 and 1988 
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X.400 versions. The reason for RFC822's overwhelming success is that X.400 is 
so poorly designed and complex that it is difficult to implement well [Ref 7:p. 
646]. MIME is a direct result of the difficulty involved attempting to bring X.400 
to the commercial market. In the end, it was easier to fix SMTP and develop 
MIME instead. X.400 message addresses also require lengthy attribute fields 
which are unnecessary and far more cumbersome than the normal usemame@ 
hostname, subnetwork format on used by RFC822/MIME/ SMIME. However it is 
possible to send e-mail between X.400 and RFC822-based e-mail systems, though 
conversion between is required and most commonly done using special gateways. 
However such a gateway might easily be put into the MOC to access the X.400/ 
DMS customers as required, while MIME should be used over the rest of the 
radio-based portion of the WAN in order to reduce address overhead. 

In theory, all that can be done with MIME can also be done with X.400, but 
the user base and product support are not as widespread for X.400. Given the 
choice between a simple widespread working model and a supposedly wonderful 
but non-working X.400 system, most implementers chose RFC822 (including 
NRaD which uses Qualcomm's Eudora, a RFC822 based e-mail program for its 
Battle Force E-mail system). The bottom line is that an IP-based network carries 
IP datagrams and is not concerned whether the e-mail application is based on 
RFC822, MIME, S/MIME, X.400 or all of the above. However, any e-mail 
application must be easy to implement, or it won’t be used effectively. Therefore 
the proposed AMCM system is based in RFC822 and MIME. 

E. COMMON DATA DEFINITION 

The purpose of using common data definitions is to ensure that the informa¬ 
tion can be input, read, modified, and used on multiple platforms, independent of 
manufacturer or operating system. It is absolutely essential that the data elements 
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be defined consistently throughout MIW and other communities. Standard data 
definitions and image formats must be used in order to interchange information 
over a cross-platform, community-wide, relational database. Common data 
definitions provide data interoperability between sensor, processor, decision 
support modules and the user. For example, minehunting information gathered 
from multiple sensors is used by the Target Location (TARLOC) program to 
calculate mine-like object locations. This calculation can be done by a processing 
module on the AMCM platform itself, by a processing module in the MOC, or by 
a JMCIS/MEDAL station without requiring any conversion, as long as the data is 
properly defined. This can only be done seamlessly if the sensor data is provided 
in the proper format prior to entry into the TARLOC program. The most 
expedient and efficient method is to put the information in the proper format at the 
entry-level point to the network. For example, the data elements that must be 
properly defined to catalog and calculate a contact's location using TARLOC 
includes minelike contact number (mile#), timestamp, position (latitude & 
longitude), altitude (alt), navigational error (e or a), aircraft heading/skew, sonar 
speed/depth and cable length as shown in Figure 5.3. 


mile# 

time 

Lat 

Long 

e 

A/C 

A/C 

A/C 

sonar 

sonar 

cable 





o 

hdg 

skew 

alt 

speed 

depth 

length 


Figure 5.3. Timestamp Data Elements 

These data elements, once properly defined, may be grouped into the text 
type category for message composition and included as an e-mail message. 
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Additional types of data such as imagery, audio and video may be attached and 
forwarded as well. 

JMCIS is an example of a tactical decision aid that uses such data defini¬ 
tions. It uses a common operating environment with strict data definitions to 
ensure interoperability between segments such as MEDAL. AMCM O'*! Informa¬ 
tion System will include JMCIS/MEDAL as a node on the network in order to 
achieve the tactical interoperability objectives desired. To do so seamlessly, the 
JMCIS data element definitions must be used as much as possible. Because the 
JMCIS data element definitions are used by the originating host to draft the 
original mine-like contact reports, the data is compatible for MIW MEDAL data¬ 
base entry as soon as the mine-like contact is determined to be valid without 
requiring data element conversion. 

F. SNMP 

Simple Network Management Protocol (SNMP) presented in RFC 1448 
[Ref 10 ], provides a systematic way of monitoring and managing a computer 
network. The SNMP managed network model consists of four components: [Ref 
7:p. 632] 

1. Managed Nodes (which contain management agents) 

2. Managed Stations 

3. Management Information (which runs a management platform) 

4. A management protocol 

These components are examined in the following sections. 
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1. SNMP Agent 

To be directly managed by SNMP, the node must be able to run a SNMP 
management process called an SNMP agent. Each agent maintains a local data¬ 
base of variables that describe its status and affect its operation. All of these 
variables (objects) are maintained in the Management Information Base (MIB). 
The typical managed nodes include routers, bridges, hosts etc. However, any 
device that is capable of communicating information on its own status may also be 
part of a SNMP managed network. SNMP agent "kits" are available for numerous 
devices, including uninteruptible power supplies. Kits may also be developed for 
sonobouys, radio navigation receivers, modems, radios, even in sonar console 
processors. 

2. SNMP Management Station 

Network management is done from management stations which are nothing 
more than computers running special management software. The management 
stations contain processes that communicate with the agents over the network by 
issuing commands and eliciting responses. The complexity of this system resides 
in the management station. This keeps the agents as simple as possible and 
minimizes the workload on the device hosting the agent software. The manage¬ 
ment station is able to interact with the agents using the SNMP protocol. By using 
SNMP protocol, the management station is able to query the agent and if 
authorized, change the variables that describe the state of the agent. Normally the 
management station sends a request to the agent asking for information or 
commanding it to update its state. The agent usually replies with the information 
or confirms that its state has been changed as requested. Errors can also be 
reported if a incorrect variable is used. Seven different message types can be sent 
using SNMP. Six are from the initiator and the seventh is the response message 
from the agent as shown in Figure 5.4 below: [Ref. 7:p. 643] 
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MESSAGE 

DESCRIPTION 

Get-request 

Requests the value of one or more variables 

Get-next-request 

Requests the variable following this one 

Get-bulk-request 

Fetches a large table 

Set-request 

Updates one or more variables 

Inform-request 

Agent-to-manager message describing local MIB 

SnmpV2-trap 

Agent-to-manager trap report 

Response message 

Response to request message 


Figure 5.4. SNMP Message Types 

Assets on a SNMP managed networks can be monitored and remotely managed 
from a central location. 

G. SUMMARY 

Common interfaces are critical to the success of the any information 
system. The commonly defined data elements allow data to be read and used on 
different TDA’s, databases, processors etc. without requiring conversion or manual 
reentry. The LAN hardware interfaces ensure compatibility and flexibility 
between the modular components. The Envelope Definition defines the wrapper, 
whose contents may be in text, imagery or even video segments. TCP/IP and 
SNMP Protocols are used to manage the network and provide compatibility to 
access information over networks worldwide. The AMCM Information 
System architecture can accommodate any sensor or decision support computer 
that subscribes to these interfaces, i.e. any system that has built-in or added 
Internet compatibility. 
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VI. REQUIREMENTS PERSPECTIVE 


A. INTRODUCTION 

This chapter presents the overall mission requirements and the tradeoffs 
involved in achieving these requirements. 

B. OVERVIEW 

Given many requirements, it is important to keep the larger goal in mind at 
all times and to translate local actions into global results. However, it is also 
imperative to realize that there is no single larger picture. There are numerous 
larger pictures to consider, each larger than the predecessor. For example, a local- 
area network may be formed by integrating the G^I assets in the Mobile Operations 
Center (MOC). Another local-area network (temporarily palletized) can be formed 
by integrating the C'*! assets on board the AMCM helicopter. Finally, integration 
of various communications and cryptographic equipment into each of these LAN's 
to form a radio-based wide-area network that passes data between the mobile MH- 
53E LAN and the mobile operations center (MOC) LAN forms an even wider 
information system. Finally, the system may be further expanded as additional 
MH-53E mobile LAN's and shore- based LAN's are added to the overall system. 
The picture will continually evolve and grow in scope. However, to ensure that 
the system is not limited beyond the immediate mental focus of the designer, the 
system must be designed from the most basic level to use open standards and an 
open architecture so that it is scalable and flexible at all levels, now and in the 
future. 

C. SOLVING THE RIGHT PROBLEM 

Part of the system design problem is the fact that system will be constantly 
upgraded in ways that no single individual can foresee in any detail. Thus the rule: 
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"Part of systems engineering design is to prepare for changes so that they can be 
gracefully made and still not degrade the other parts" [Ref 11 :p. 5] 

Unfortunately, many solutions are often offered that can solve the wrong 
problem correctly. Systems Engineering involves solving the right problem. This 
thesis has established that the proper focus is on the data, not the data link. The 
solution to the problem is based therefore on determining what data flows are 
required between each LAN. 

D. STATED REQUIREMENTS 

The MIW C^I Requirements Document states that "as a minimum, a data 
link will provide the following: 

a. MCM asset position 

b. Parameters to compute trailback and offset of MCM gear. 

c. MCM equipment settings/performance data, when sweeping. 

d. Sensor video and/or digital sonar image data, when hunting 
(primarily for unmanned systems)" [Ref 12:p. 2] 

Sensor video and /or digital sonar image data is also listed as a periodic or 
as- needed transmission under the MIW C*! Requirements Document. Video is 
not stated as a clear requirement. The wording of the statement,"video and/or 
digital sonar image data," implies that imagery is an acceptable substitute for 
video. 

PMS-210, (the AMCM Program Executive Office), has stated that the 
priorities for the system are as follows: 
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1. Real-time aircraft position/location information (PLI), 

2. Near-real time sonar data, 

3. Over-the-horizon range is desired. 

"Sonar data" includes mine-like contact position information and imagery of mine¬ 
like objects or video if possible. 

E. TACTICAL OBJECTIVES 

Before examining the differences between video and sonar imagery, we 
shall reconsider the purpose of the AMCM squadron. In many cases AMCM acts 
in the role of precursor sweeping and fast reconnaissance. The sonars employed 
by the AMCM assets are for search and not classification. Therefore, the purpose 
AMCM mine-hunting missions is not to analyze a mine-like object in an attempt to 
identify mine-type. Rather AMCM mine-hunting missions are tasked to provide a 
quick surveillance of the area to confirm the presence and location (if possible) of 
mine-like objects. If mine-like objects are discovered, other assets may be 
employed in order to destroy or neutralize them. AMCM may also be redeployed 
to revisit the area with equipment specifically designed to: 

• Cut the cable of a moored mine 

• Use acoustic/magnetic influence devices to actuate an influence mine 

The primary information that must be passed is an indication of whether or not 
mine-like objects are present and, if present, the location of these objects. Armed 
with this information the Commander can proceed to the next step: avoidance, 
destruction, or neutralization. 
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F. REAL REQUIREMENT 


The real requirement is to deliver a sufficient amount of "critical informa¬ 
tion" in near-real time latency period (measured in tens of seconds) in order to 
provide a near-real time mine avoidance capability to the fleet. The system should 
not care not care whether the data format is text, video or single frame imagery, 
but only that the critical information is delivered in near-real time in a usable form 
to all levels where the necessary decisions must be made. In order to achieve this 
required objective, "critical information" must be explicitly defined and efforts 
must be made to minimize the amount of time that it takes to process, analyze and 
act upon this information. 

1. Critical Information 

Critical information consists of information that is crucial to success. 
Information crucial to success in AMCM includes the following: 

a. Mine-like object position information. Crucial for prosecu¬ 
tion by surface MCM and EOD assets and for avoidance of mine danger areas by 
shipping. 

b. AMCM and surface based MCM identification and asset 
positions. Crucial for deconfliction and safety of flight. 

Essentially, either mine-like objects are confirmed in the operating area or 
are failed to be confirmed as they may not be detected or actuated due to variety 
of reasons including malfunctioning equipment, burial, navigation errors, etc. 
However, once detected, an accurate mine-like object position report must be 
made available as soon as possible. 

2. Near-Real Time Transfer of Information 

The only way to have a near-real time mine-avoidance capability is to have 
the information that makes mine-avoidance possible available in near-real time. 
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Therefore the objective is to minimize the amount of time required to process and 
transfer the information from the sensor to the decision maker. Numerous inter¬ 
related issues are involved in achieving this objective. These issues include, but 
are not limited to the following: range, throughput, processing, format, packaging, 
scalability, manpower, security, available technology, and cost. 

These issues are discussed in following section as they are requirements 
that must be considered in conjunction with the near-real time capability issue. 

G. ENGINEERING ISSUES 

The following issues must be considered in conjunction with the near-real 
time capability requirement. 

1. Range 

Range is a crucial issue involved in the delivery of critical information to all 
levels where the necessary decisions must be made. If the MH-53E AMCM asset 
is out of range, no information will be delivered as connectivity cannot be estab¬ 
lished over the radio-based WAN. Ultra High Frequency (UHF) radios are limited 
to line-of-sight (LOS) communications. During AMCM operations, LOS range is 
typically 20 nautical miles. Unless satellite communications or High Frequency 
(HF) radios are used, information will not be available in near-real time in ranges 
beyond LOS. HF radio communications using surface waves typically provide 
over-the-horizon (OTH) ranges of 100 nautical miles. AMCM operations require 
OTH connectivity as operations are often performed in ranges beyond LOS. 

2. Throughput 

Throughput is a crucial issue as it directly impacts the speed in which 
information can be delivered over the radio-based WAN. Throughput is affected 
by numerous factors such as compression, modulation, bandwidth of the data 
channel, and the quality of the communications link itself. Typically, as any of 
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these factors increase, so does the data rate. Standard HF channels have a band¬ 
width of 3 KHz and support data rates of 2.4 Kbps (less than a typical home 
telephone modem). This rate may vary due to error correction, link quality, 
protocol performance etc., but the amount of information that HF can transfer in 
near-real time is extremely limited in comparison to UHF. 

Standard UHF channels have a bandwidth of 25 KHz and support data rates 
of 16Kbps. However, UHF radios and modems are readily available that modify 
the standard UHF channel bandwidth to support near-real time data rates from 
Kbps to 2Mbps. Due to the higher throughput, UHF radio-based systems are able 
to support a wider range of multimedia applications such as audio, imagery and 
video. 

Due to HF radio communications restricted throughput, HF usage should 
be limited to text based messages and small single frame images for supporting 
near-real time operations. Therefore imagery, not video, is the preferred method 
of transporting mine-like object images which are to be displayed, as HF commun¬ 
ications will not support "video" throughput requirements. 

3. Processing 

The best way to minimize the amount of time required to process informa¬ 
tion, is to process as much as possible at the source. This reduces the amount of 
unprocessed information that must be transferred and processed upon arrival. 

Only pertinent information is transferred for further evaluation by the decision 
nodes. Less transfer time and/or throughput is required through bottleneck links 
because less data must be transferred. 

There are several options available to increase the amount of processing at 
the source. The biggest impact would be through the use of computer-aided 
detection (CAD) algorithms on board the MH-53E. This will provide automated 
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on-site real-time sonar video processing in addition to the sonar operator’s manual 
scanning process. The calculation of mine-like object position reports using 
information from the various sensors can also be processed on-board the MH-53E. 
This will further reduce the amount of sensor information which must be passed 
over the radio-based WAN. 

4. Format 

The critical information must be in the proper format so that the information 
can be directly analyzed by the decision maker. This can be accomplished in near- 
real time as long as: 

• The information is properly defined 

• The information is in a format that is usable upon delivery without 
requiring multiple conversions 

The format of the data can be either text, imagery, audio or video depending 
on the ability of the communications channel to support delivery in near-real time. 
The format must be applicable to the path used for delivery. The critical informa¬ 
tion must be converted (i.e. from video to imagery or from imagery to text based 
position reports) if the channel cannot support near-real time delivery of the 
information in its original format. 

5. Packaging 

In order for the information to be available in near-real time, all relevant 
information must first be gathered and packaged together. Proper packaging 
includes the ability to contain and combine all relevant data independent of its 
format, i.e. video, audio, text or imagery. For example, a mine-like object’s 
image, position, time, etc. must be contained within the same package. The 
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package must be addressable and secure to ensure near-real time delivery of 
information to decision makers. 

6. Scalability 

The system must be able to evolve as more assets are added to the overall 
network without reducing the near-real time performance capability desired. The 
open architecture ensures that the individual MH-53E assets are capable of 
performing as much of the processing efforts as possible so as not to overload the 
processing capabilities in the MOC. The use of open standards throughout each of 
the networks ensure that the system itself can easily evolve as individual compon¬ 
ents or software upgrades become available without causing cascading changes 
between modules. 

7. Manpower 

Additional manpower is not available in the MOC or MH-53E to assist in 
the near-real time processing or delivery of critical information. As numerous 
AMCM operations forward critical information to the MOC in near-real time, 
information overload is possible unless the data flows are minimized to contain 
only relevant information which is ready for use by decision makers upon arrival. 
No further action should be required to the critical information as such actions are 
potential bottlenecks to the information distribution process. Considerable life- 
cycle savings are possible as manning requirements may be reduced in the MOC 
due to automated processing and conversion of information. MH-53E helicopter 
manning will remain unchanged for this proposed architecture since the AMCM 
C'*! Information system will run in the background with no additional manual 
effort required. 
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8. Security 

Security must be transparent to the end user and not impact the speed at 
which information is transferred. Data rates up to 1.544 Mbps (T1 capacity) are 
possible using KG-84C compatible link-encryption devices over the radio-based 
WAN. The data should also be secure within the MOC LAN portion of the 
AMCM tactical network itself. This can easily be performed by using one of 
several secure e-mail programs available today to provide information confiden¬ 
tiality and authentication inside a physically secure LAN. 

9. Available Technology 

Commercial-off-the-shelf (COTS) and non-development-item (NDI) 
components are available today that support near-real time transmission of video, 
imagery and text over IP compatible LANs and radio-based WANs. However, 
modifications are required to the existing AN/AQS-14A sonar interface as the 
current system has no interface capable of transferring sonar video information to 
the MH-53E AMCM 0^1 network itself Several interface options have been 
proposed by the manufacturer. 

CAD can be made available for use on the aircraft if desired. An Ethernet 
interface card can be installed into an empty VME slot in the CAD Post-Mission 
Analysis (PMA) Workstation to interface with the network on the MH-53E LAN- 

The PMA VME-bus-based cards would also need to be packaged for 
airborne use. Finally the Mission Planning Station can be attached to the MOC 
network simply by installing an Ethernet network interface card (NIC). 

10. Cost 

The marginal cost to achieve near-real time AMCM command and control 
is minimal, considering that most of the assets are already in place. LANs 
(optionally palletized) must be installed in the MOC and MH-53E helicopters. 


51 



However these systems can be built in phases as components evolve and are added 
to the network. Communications equipment may also be added incrementally as 
desired. The transmission of sonar video and the use of CAD on board the MH- 
53E are not stated requirements. If CAD is not used on the aircraft and video is 
not transferred over LOS using a UHF channel, the most significant costs in the 
palletizable system will be the Ethernet interface to the AN/AQS-14A and a HF 
radio/modem. Thus all component/software costs are minimal. 

Where initial high component costs can potentially become involved is if 
CAD is used to process sonar video locally on the MH-53E, or if UHF equipment 
is used to transmit the sonar video in order for the video to be remotely processed 
by either manual operators or CAD in the MOC. These are options which can be 
added to enhance the processing of the sonar video information in near-real time. 

In any case, the sonar video has always been "processed" in real time by the 
sonar operators on board the MH-53E. The sonar operators currently review the 
sonar tape in real time and "mark" mine-like contacts as they appear on the screen. 
The entire sonar video is also stored on magnetic tapes which may be reviewed by 
manual operators upon the helicopters return. With the addition of the tactical 
network, the system may be configured so that the operator may select mine-like 
contacts and forward position, imagery and even sonar video information over 
either a HF, UHF or even SATCOM channel; in otherwords, (because it’s a true 
internet), over any and all of the above. For example, routers are capable of 
sending 3 packets of data to the HF queue, 8 packets to the UHF queue and 5 
packets to the Satcom queue - all of which are part of the same e-mail message. 
The end system TCPs are perfectly capable of reassembling the packets back 
together to form the same original single e-mail message. 
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11. Options 

Although near-real time video processing by any other method than the 
operator on board the helicopter is not required, the merits and deficiencies of the 
options available are worthy of further discussion. 

There are three options available to process the sonar video in near-real 
time. The first option is to use CAD locally on the MH-53E. With CAD installed 
on the aircraft, the operational range in which information from CAD will be 
available is greatly improved as near-real time sonar video processing capability 
will no longer limited to operations within LOS. The relevant mine-like contact 
information extracted from the processed video can be filtered into sizes accept¬ 
able for HF or Satcom transmissions world-wide. The only way to process the 
necessary information on the aircraft with the same level of "scan" as in the MOC 
is to embed CAD into the aircraft system. This way you still get one operator and 
one automated "look." This is possible as the Post-Mission Analysis Station 
computer-aided detection algorithm can be added to the LAN in the MH-53E by 
installing an Ethernet interface card in one of the empty VME slots in the PMA 
Station. Other options include installing the algorithm in a different processor 
either by using the existing VME cards or by porting the software to a separate 
host, such as a VME based TAC-4 processor. The sonar video tape will still 
available for review upon aircraft return, or even while in transit as it is possible to 
send some information ahead. 

The second option is to process the sonar video remotely in the MOC. To 
be able to process sonar video in near-real time in the MOC, additional UHF 
communications equipment is required on the helicopter and in the MOC, as the 
UHF transceiver that must be used to provide the data channel will be fully tasked 
and unavailable for voice communications. Therefore an existing voice radio 
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cannot be substituted or borrowed for the data channel communications. However 
use of UHF to transmit the sonar video so that CAD or manual operators located in 
the MOC can be used to process the sonar video in near-real time ultimately limits 
the real-time capability to LOS operations only. Additional problems arise when 
numerous mine-hunting operations are simultaneously trying to transfer sonar 
video information to the MOC. This requires additional hardware and personnel 
resources to manage the additional volume of information. 

The third option is to continue doing what is being done now, with the 
exception that when spotted by sonar operator, the mine-like object’s imagery and 
position location information can now be forwarded to the MOC via the tactical 
internet using standard HF communications equipment. As before, this option 
relies completely on the sonar operator on board the helicopter to manually pick 
out minelike image from the sonar video and send mine-like object images OTH 
using the HF path. CAD may still be used to process the entire sonar video tape 
upon return of the aircraft to the MOC. The end result of this option is that the 
tape will only be processed in real-time by the sonar operator, who will not be 
supported by CADs automatic detection algorithms. 

H. SELECTION OF SONAR VIDEO PROCESSING METHOD 

Of the three options, the eventual installation of CAD on board the MH-53E 
is the best choice for several reasons. 

First it provides a consistent baseline for target detection. Operator training 
and experience varies widely in the fleet. This has previously led to a high level of 
false AN/AQS-14 contacts being reported. Over time, a lack of trust from the 
"marking" of too many false "mine-like" objects led to the development of 
standard operating procedures which required the tactics officer to review each 
mine-like object and approve its "quality" prior to release to the MIW community 
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as a mine-like contact. Policies such as these have added considerable delay to the 
system. A new CAD software version has reeently been developed and released 
by the manufacturer which has a very high level of probability of detection. 
Therefore, CAD can be used as an onboard tool. It will assist the operator by 
highlighting potential targets as they appear on the sonar operator’s screen. 
However, the operator still can have the final say on whether or not the contact is 
"marked." 

Seeond, CAD on board the MH-53E provides the highest level of process¬ 
ing without requiring the addition of personnel or equipment to the MOC. In fact, 
the level of observation in the MH-53E with CAD on board may in some cases be 
better than in the MOC as the sonar operator in the aireraft is able to focus only on 
that one mission, while MOC sonar operators may be tasked with several missions 
simultaneously if multiple video signals are being received and if the CAD Post- 
Mission Analysis Workstation is already being used. 

Thirdly, CAD in the aircraft helps to eliminate potential data-fusion 
problems due to information overload in the MOC, by eliminating the desire to 
send video at all. CAD in the aireraft will eventually diffuse the pereeived video 
requirement once near-real time TARLOC position reports of mine-like objects 
marked and forwarded from the aircraft are shown to be accurate, without any 
assistance fi'om the ground. 

Fourthly, CAD in the aircraft reduces crew workload both in the aircraft 
and in the MOC as the data will be fully filtered and processed at the source. This 
ean lead to less manning and considerable lifecycle savings in the MOC in both 
equipment and material. Although CAD doesn’t directly provide longer range of 
operations, it helps reduce the data flows to levels which can be met by HF and 
UHF SATCOM throughputs. Therefore CAD processed information can be sent 
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over longer ranges that are only available using narrow bandwidths such as HF and 
SATCOM. 

Finally, CAD costs may be significantly reduced as the Remote Mine- 
Hunting System (RMS) system contract has recently been awarded to Lockheed 
Martin. The RMS system will use the same AN/AQS-14A sonar (with an 
improved CAD system) as the AMCM community. It is possible to build the 
AMCM internetworked system now in the aircraft without CAD. CAD can be 
added later on, most likely with less cost. In the interim, the system will then be 
the same as that presented in option three, using only the operator to scan the sonar 
video. However, based on the author’s experience as a squadron tactics officer, 
this is the best path since the real purpose of AMCM surveillance and fast recon¬ 
naissance mine-hunting missions is to provide a near-real time mine avoidance 
capability. The mission is to see if there are mine-like objects in the area; not to 
find every mine-like object in the area, and the AMCM sonar operator has consis¬ 
tently proven the capability to do that. 

I. SUMMARY 

The real requirement is to provide a near-real time mine avoidance cap¬ 
ability to the fleet. This can effectively be done OTH by sending position mine¬ 
like object location and single frame sonar imagery information processed in near- 
real time on board the AMCM MH-53E assets. 
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VII. RELATED WORK 


A. INTRODUCTION 

This chapter discusses related work. Plans, publications, programs, 
scheduled future demonstrations, as well as results from the Gulf of Mexico 
Exercise ‘94 (GOMEX) prototype system, are presented to provide an overview of 
the current AMCM O'*! situation. 

B. PLANS AND PUBLICATIONS 

The following publications officially address C^'I for the Mine Warfare 
community: 


Mine Warfare (MIW) C^I Master Plan [Ref 13:para 3.9.3] 

• Mine Warfare (MIW) C^'ISR Operational Architecture [Ref 14] 

• Mine Warfare (MIW) C^ISR Systems Architecture [Ref 15] 

• C'^I Architecture Currently Supporting the Mine Warfare Community 
[Ref 12:p. 2] 

• MIW C^I Requirements Document (COMINEWARCOM, 1 June, 

1995) 

1. Mine Warfare (MIW) C^I Master Plan 
The following is quoted from the Executive Summary of the MIW C'*! 
Master Plan. 

The MIW C‘‘I Master Plan (MIWCMP) is one of a series of plans in 
development at the Space and Naval Warfare Systems Command 
(SPAWAR) designed to implement the Navy's portion of the JCS C'^I 
for the Warrior concepts through the objectives and vision of 
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Copernicus...Forward.... The bottom line is that the SPAWAR MIW 
O'*! Master Plan is designed to assist CNO, SPAWAR, PEO 
MINEWAR, and other SYSCOMS to provide Mine Warfare with the 
O'*! tools necessary to meet current and emerging challenges... 


However, it must be understood throughout the MIW community that 
"Mine Warfare" in the SPAWAR context is principally focused on Mine Warfare 
Ships. AMCM requirements and systems integration aspects are presented, but 
they in no way drive the architecture, requirements or systems integration plans for 
the overall MIW community. The "MIW community" in SPAWARs MIW O'*! 
Master Plan lacks integration and balance. 


The SPAWAR MIWCMP is designed to document the strategies, 
plans and programs involving Command Control Communications 
Computer and Intelligence (Cl) capabilities for the Mine Warfare 
Ships currently under CNO and SPAWAR sponsorship. 

This is evident as the MCS, MCM, and MHC are all strongly represented 
on the Systems Installation Planning Schedule, and no installations are planned 
between FY 97 and FY04, (the entire range of the chart) for all non-SMCM assets 
listed under MICFAC, MAST, EODC^I, SEAL C'^I, and Airborne C'’! in the 
Deployable Communications category. 

The SPAWAR MIW C*I Master Plan is extensive and provides a great level 
of detail for the SMCM community. However, as it clearly states, its primary 
focus is on surface based MCM assets. The entire AMCM section from the MIW 
Cl Master Plan is included below: 


All military aircraft are presently equipped with HF, UHF and/or 
VHF secure and/or non-secure voice systems. Present systems 
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should be used to fulfill all voice reporting requirements. No 
decision has been made to date on whether one of the existing 
Tactical Data Link circuits should be used to pass near-real time 
acoustical data, or if a new MIW unique system should be 
developed. As an interim measure a Link-11 type system 
(compatible with the MICFAC and MCS-12) could be deployed on 
the MH-53E AMCM aircraft. This interim system should be 
configured in such a way as to be deployed on a pallet until a 
permanent solution is identified. 


AMCM is only specifically addressed in two other instances in the MIW 
Cl Master Plan. First, the SPAWAR MIW C'^I Master Plan states that there is no 
AMCM plan. 


Though a requirement exists for a Tactical Data Link to pass data 
from the MH-53 to the MCS, there has been no resolution as to 
whether one of the existing link architectures will be used, or if a 
new concept is to be developed for Mine Warfare. 


Second, MAST is "selected" to support AMCM even though it’s 
procurement and/or installation hasn’t been planned. "MAST has been selected to 
provide deployable C'*! for the AMCM commander." [Ref 13:para 3.9.3] 

2. Mine Warfare (MIW) Command Control Communication 
Computer and Intelligence Surveillance and Reconnaissance 
(C'^ISR) Operational Architecture 

The MIW C^ISR Operational Architecture is also part of the series of 
documents from Space and Naval Warfare Systems Command (SPAWAR). The 
MIW C4ISR Operational Architecture proclaims that is a 


standards-based blueprint that will serve as the official source 
document containing the operational requirements, nodal 
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descriptions, operational activities (or tasks), and information 
exchange requirement (lER) information for MIW. 

This document identifies an overall MIW operational hierarchy. It defines the 
scope of the C^I architectural problem in terms of operational command 
relationships, operational information exchange requirements and MIW nodal 
connectivity. The Mission Need Statement for Mine Warfare C^^I System is 
provided in Appendix E. AMCM operational background information is provided 
in section 3.3.2.4. It is important to note that the Operational Information 
Exchange requirements listed in (Figure 7.1) C'^ISR Operational Architecture) 
cannot be supported with the equipment listed for the MH-53E in MIW Node 
Connectivity - Communications Systems diagram as shown in Figure 7.2 C'^ISR 
Systems Architecture). 

3. Mine Warfare (MIW) C‘*ISR Systems Architecture 
The MIW C'‘ISR Systems Architecture is also part of the series of 
documents from the Space and Naval Warfare Systems Command (SPAWAR). 
This document presents and provides the Mine Warfare MIW C^I Systems 
Architecture as a roadmap and a subset of the Naval Command, Control, 
Communications, Computers, Intelligence, Surveillance, and Reconnaissance 
(CISR) Architecture which can support MIW, Joint, Allied, and Coalition forces, 
and support force interoperability and battlespace dominance. The MIW C'^I 
Systems Architecture, when implemented will satisfy the operational activities, 
lERs, operational nodal connectivity identified in the MIW C'*! Operational 
Architecture, and provide top-level performance boundaries. [Ref 15] 
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Figure 7.1. Operational Information Exchange 
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Figure 7.2. MIW Node Connectivity - Communications Systems 
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Figure 7.3. MIW Node Connectivity - Processing Systems 
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This document provides a high level overview of MIW Cl mission require¬ 
ments and interoperability issues. Figures 7.2 through 7.3 provide insight to what 
is planned for AMCM. No specific AMCM System Architecture is provided. The 
MIW Node Connectivity - Communication Systems diagram, (Figure 7.2), reveals 
that terminal teletype (TTY) and secure voice (SVOX) are the only existing/ 
planned AMCM communication system requirements needed to support the 
AMCM functions required in the conduct of MIW. Also, the document is not 
complete as the MOC Van, required when the AMCM unit is not on MCS-12, is 
not included in the MIW Node Connectivity - Communications Systems diagram 
(Figure 7.2). 

4. C'*! Architecture Currently Supporting the Mine Warfare 

Community [Ref. 16] 

This was prepared by LANTFLT Systems Engineering in March ‘96 
following a four-day review of the C^I architecture currently in use within the 
Mine Warfare community. "The objective was to determine the as-is C'*! 
architecture and data flow requirements of units involved in Mine Warfare." [Ref 
16:p. 2] Shipboard and CMWC based hardware/software systems were examined 
as well as issues concerning upgrading MIW nodal capabilities. A list of C^I data 
requirements are also presented. The data requirements are broken down into 
continuously supplied data and periodic supplied data categories. The contin¬ 
uously supplied data can be further broken into intrinsie "raw" data and derived 
"calculated" data. This document provides no guidance on specific AMCM 
systems as they were not examined. Finally, the SPA WAR series of documents 
listed in the proceeding paragraphs were based on the information contained in 
this document. 
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5. MIW C"*! Requirements Document [Ref. 12] 

COMINEWARCOM’s MIW Requirements Document identifies the 
fundamental requirements for a "tactically effective MIW C*! system." It states 
that a "MIW Cl system is to be a segment within the Joint Maritime Command 
Information System (JMCIS) to provide interoperability with Navy, Joint, and 
Combined C*! systems and therefore will comply with USN Copernicus architec¬ 
ture requirements." Data transmission requirements listed include both beyond 
line of sight (BLOS) and within line of sight communications. Continual as well 
as periodic transmissions are also required. The document also states that "as a 
minimum, a data link will provide the following:" 

1. MCM asset position 

2. Parameters to compute trailback and offset of MCM gear. 

3. MCM equipment settings/performance data, when sweeping. 

4. Sensor video and/or digital sonar image data, when hunting 
(primarily for unmaimed systems). [Ref 12] 

The data flow requirement descriptions contained within this document are 
extremely valuable in determining the required data flows between MIW assets. 

C. PROGRAMS 

1. The AN/AQS-20 Data Link 

The AN/AQS-20 Data Link currently under development by Raytheon. It is 
a point-to-point, UHF line-of-sight data link with a throughput of 250 Kbps. The 
system is based on the 1553 data bus and the Navy Communications System 
(NCS) "glass cockpit upgrade." The system will add a third AN/ARC-210 UHF 
radio, a SSE DSM-102 Satellite Modem to the aircraft, and a DVME-739 serial 
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communications controller card to the AN/AQS-20 console processor module D. 
The simplex (send-only) system will supply unencrypted AN/AQS-20 sonar video 
only within LOS ranges to the MOC. Currently, only R&D has been funded for a 
prototype system. The AN/AQS-20 sonar and data link is scheduled to reach the 
fleet in 2003. 

The AN/ARC-210 and the SSE DSM-102 were utilized in the AMCM C^I 
Information System proof-of-concept demonstration as part of the radio-based 
WAN. This was intentionally done to demonstrate how to convert this system to a 
secure, network-compatible system that can be used for all missions not just the 
AN/AQS-20 mine-hunting mission. 

2. MAST 

Mobile Ashore Support Terminal (MAST) is a self contained, transportable 
C'*! system which can be rapidly deployed to meet any contingency. MAST 
provides an initial Cl capability for a naval detachment operating ashore. The 
MAST capabilities include a comprehensive communications suite: HF/UHF/ 
VHP, SATCOM and associated crypto gear; a C2I capability: JMCIS/GCCS, GPS 
and an integrated briefing system. [Ref. 13:para 3.9.3] According to SPAWAR's 
MIW C'*! Master Plan, MAST has been selected to provide deployable G^I for the 
AMCM Commander. However, it is unknown whether it has been funded or if 
funded, when it will be made available to the AMCM squadron. MAST currently 
costs $1.25 Million and is expected to require 1 year to deliver. MAST does not 
integrate the current AMCM G^I assets into a coherent system or improve connec¬ 
tivity with the MH-53E. 

3. Remote Minehunting System (RMS) 

Lockheed Martin was awarded the Remote Minehunting System (RMS) 
contract in August '96. The RMS consists of a semi-submersible diesel submarine 
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that tows the AN/AQS-14A side-scan sonar. The submarine is unmanned and the 
RMS will be controlled using a LOS UHF data link. The LOS data link will also 
provide sonar video data and target location information. The RMS sonar system 
is to be based on a VME bus with Ethernet ports to the sensor and to the data link. 
Computer-aided detection (CAD) will be added to the system as a future upgrade 
using 8 additional VME cards. Two MVME-167 VME cards will provide 
Ethernet interface to connect the Ethernet-based sensors and data link to VME bus. 
One MVME-167 card will act as a sonar data interface and perform sonar data 
routing fimctions. The other MVME-167 card will act as the image compression 
interface and control and perform message collection functions. A UHF radio will 
be used to transmit the data to the command and control platform. 

The sonar to be used in the initial RMS version (AN/AQS-14A) is also 
employed by the MH-53E. The AN/AQS-14A sonar used in AMCM requires an 
upgrade inorder to gain Ethernet access. However AN/AQS-14A upgrades being 
made for the semi-submersible RMS system can also can be used with AMCM’s 
AN/AQS-14A. Common software engineering, research and development, and 
logistics costs can be drastically reduced if these components are used for the 
AMCM upgrades to the AN/AQS-14A. It is essential that common definitions and 
interfaces be identified early on in order to be interoperable and to take advantage 
of this parallel effort. 

4. Link-ll 

Link-11 is a two-way secure, netted link that exchanges information in the 
TADIL-A message format. Link-11 functions as a primary data link for surveil¬ 
lance, combat weapons coordination and battle management. Link-11 configura¬ 
tions vary as it may be used over both HF and UHF radios. Link-11 maximum 
throughput is 6 Kbps, which will not support video. Link-11 is not currently 
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programmed for MCMs, MHCs or AMCM MH-53E. MCS-12 received Link-11 
during the conversion process. The MOC has Link-11 installed. 

5. Link-16 

"Link-16 is not currently programmed for MCMs or— MHCs or MCS-12. 

It should be a future requirement for MCS-12, MCMs, MHCs, MICFAC, MAST 
and the COMINEWARCOM (CMWC) Command Center." [Ref 13:para 3.4.2.2] 

Though Link-16 is to be the primary data link for the USN, it is restricted to 
LOS. In full ECCM mode, it supplies only 28.8 Kbps and lacks the throughput to 
support video. Since it is based on Time Division Multiple Access (TDMA), less 
time is available to each user as more users are added. As a result, because each 
user has less time to transmit/receive data, the throughput will degrade as the 
number of users on each net is increased. It will be expensive and will not solve 
all the problems that expectations will place before it. 

6. Lmk-22 

NATO Improved Link Eleven (NILE)/Link-22 is an improved version of 
Link-11. Through TDMA, it will be capable of multinetting with a gapless cover¬ 
age over 300 NM range by combining HF with UHF line of sight nodes. The link 
will be based on TADIL- J series data elements and messages. Link-22 is not 
currently programmed for MCMs, MHCs or MCS-12. [Ref 13:para 3.9.3] 

MIW needs a "force coordination" networked communications system. The 
tactical-conununications-based e-mail and IP network proposed in this thesis will 
meet this need. What MIW does not need is a "weapons coordination" 
communications system like Link-16, Link-11 and Link-22. These "weapons 
coordination" systems are very expensive and pose gigantic systems integration 
problems. 
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D. PREVIOUS DEMONSTRATIONS 


A previous AMCM data link system includes EDOs TLTS prototype data 
link that was used during the U.S. Navy Gulf of Mexico (GOMEX) Exercise in 
1994. This effort demonstrated the real-time capability to report aircraft, towed 
body, and mine-like object position information. The data link was also used to 
transmit single frame sonar imagery over a HF radio system. Approximately 
seven minutes were required to transfer the uncompressed single frame mine-like 
sonar images during the demonstration. The system successfully demonstrated 
AN/AQS-14 minelike contact analysis capability in the MOC as well as transmis¬ 
sion of data from the MOC to COMINEWARCOM via Link-11. 

E. FUTURE DEMONSTRATIONS 

Future demonstration efforts include the Joint Countermine Advanced 
Concept Technology Demonstration (JCM ACTD) 97-2 which includes a proposal 
for a MH-53E data link. This system is outlined in the Joint Countermine (JCM) 
Advanced Concept Technical Demonstration (ACTD) Command, Control, 
Communications, and Intelligence (G^I) Component [Ref. 17]. The JCM ACTD 
Data Link proposes to provide preformatted position, contact and status reports 
(compatible with the display and database features of JMCIS) fi-om the MH-53E 
helicopter to the AMCM control node and the MCM Tactical Commander. The 
software on the DOS-based INC includes communications channel access proto¬ 
cols and a modified TCP/IP protocol for use over radio networks. This software 
will be used on all MIW platforms in the exercise. A RS-232 serial connection 
will be used to attach the TAC-4 to the INC. The INC is attached to the 
SINCGARS radio via a data interface device or to a KG-84C cryptological device 
from which it is connected to a HF modem and existing AN/ARC-174 HF radio. 
The bandwidth provided by both systems will not support video. The maximum 
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throughput of the line-of-sight SINCGARS system is < 9600bps. The throughput 
of the HF system will be unpredictable as the unit does not support ALE and uses 
an mechanical coupler. Finally, the detailed interfaces with existing MH-53E 
systems remain to be determined according to the May ‘96 Configurations and 
Interface Description Document. 

F. SUMMARY 

Although many MIW O'*! plans, publications, programs, and proposed 
systems exist today, no plan or system currently satisfies the overall requirements 
of the AMCM community. None of these plans, publications, programs or 
proposals integrate existing AMCM squadron assets including JMCIS/Mine 
Warfare Environmental Decision Aids Library (MEDAL), Mission Planning 
Station, Post-Mission Analysis Station, and the MH-53 E mine countermeasures 
helicopter into a cohesive C'*! system. [Ref 18] The three-part series from Space 
and Naval Warfare Systems Command (SPAWAR) is based on shipboard MCM 
requirements. AMCMs own requirements are not weighted equally in the deter¬ 
mination of the overall technical architecture. 

Finally, although the plans and programs mentioned in this chapter do not 
provide specific guidance for fully integrating AMCM C'^I assets into a cohesive 
AMCM C^*! Information System, these plans and programs do provide a invalu¬ 
able target baseline which the AMCM C^I system can reference to ensure compati¬ 
bility with other MIW C*I (systems including MCS, MCM, MHC). This reference 
baseline includes protocols, standards, message formats, which shall be compatible 
with the AMCM C^I Information System. System requirements can be deduced 
from these documents but no coherent implementation plan exists to meet these 
requirements. The architecture proposed in this thesis provides a contender 
solution which can solve this critical shortfall. 
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VIII. RECOMMENDATIONS FOR FUTURE WORK 


A. INTRODUCTION 

The AMCM O'*! Information System can be built today using a tactical 
internet to provide connectivity between all AMCM C^^I assets. This system will 
provide a significant step forward in command and control for the AMCM 
community. Future work is required to ensure all the necessary projects currently 
under development can be migrated onto the tactical internet as desired. 

B. RECOMMENDATIONS 

Numerous products are already on-line to appear in the AMCM community. 

1. Sensors 

The AN/AQS-20 sonar will be available in the year 2003. It is not based on 
a internetworked design, however the console has a VME serial port communica¬ 
tions card which can be used for AMCM LAN access. However the other inter¬ 
face definitions such as the data definitions must also be met as well to provide 
interoperability within the tactical network. The present data definitions are not 
designed for JMCIS or MEDAL interoperability. 

The RMS semi-submersible mine-hunting system and the AMCM AN/ 
AQS-14A programs must cooperate to provide as many commonalities as possible. 
This will reduce costs and improve logistics. 

This is an illustration how procurements coming out of two different 
program management offices can duplicate results in incompatible ways. Nothing 
in the acquisition system encourages them to work together. 

2. Decision Support 

AMCM’s Mission Planning System and the JMCIS mine warfare segment 
MEDAL must become interoperable. The MH-53E "glass cockpit" Navy Com¬ 
munications System (NCS) is currently being introduced to the fleet and will 
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provide the MH-53E with a 1553B data bus. The bus can be interfaced to the 
tactical network on the MH-53E using a 1553 based PCMCIA card. However, the 
MPS data module that is loaded into the overhead in the eockpit (which preloads 
and then stores all mission information trapped from the 1553 bus) is ineompatible 
with MEDAL/JMCIS. Position reports, minelike contact messages etc. cannot be 
passed between the two systems without manual conversion. In effect, the 
potential exists for two entirely separate, non-interoperable, tactical decision aids 
(TDA) to reside on the same networked platforms. MEDAL will be MIW’s 
primary TDA. However, both can be put onto the network and be interoperable 
once the message format and data definition issues are resolved. 

The era of stovepipe TDA’s like MPS has passed. Modem TDA’s must be 
LAN based, host network management platforms and use compatible data defini¬ 
tions and common operating environments like those based on the Naval Warfare 
Tactical Data Base and JMCIS/MEDAL etc. 

3. Radio-Based WAN 

Efforts to install incorrect incompatible solutions must be abandoned. 
Link-11, Link-22 and Link-16 will cost far more and be far less useful and 
effective in meeting MIW needs than a proven, widely-compatible, networkable 
yet inexpensive COTS solution like Battle Force E-mail.^ Open solutions which 
are secure, easy to clone, integrate, adopt and understand can be implemented 
with little eost or risk today. The AN/AQS-20 data link program must become 
more than a one-way, point-to-point, unsecure (unencrypted), UHF radio-based 
LOS stovepipe. The AN/ARC-210 UHF radio used by this system can be used to 
provide a secure, network compatible, high data rate UHF/SATCOM channel (as 
shown in the proof-of-concept demonstrations by this thesis). 

^B.F. e-mail uses Qualcomm’s Eudora IC based E-mail application. [Ref. 19] 
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4. Proposals 

Proposals must be made early on before it is too costly and too late to make 
meaningful changes to projects currently under development. Plarming 
Documents, Mission Need Statements, Engineering Change Proposals all will be 
required to make meaningful progress on the internetworked Cl front. 

There are numerous programs that must be integrated. Doing so will ensure 
connectivity between the necessary O'*! systems. Failing to do so will ensure 
AMCM remains standing alone and in the dark. This is evident as our existing 
baseline consists of stand-alone decision aids with no coimectivity to pass critical 
information. The problem is chronic as little or no effort has been made to provide 
interoperability between AMCM C'^I assets. By insisting on the proper architec¬ 
ture early on in the requirements part of the procurement phase, it will be virtually 
impossible for the contractor to develop anything but the proper solution. 

Finally, the move from AX.25 point-to-point connections to a reliable 
multicast transport protocol should be made as soon as possible. Like AX.25, 
NRAD’s Battle Force E-Mail system is only the first step. Use it to get a basic 
internetworked working system as soon as possible, but consider other alternatives 
that meet the networked architecture at each opportunity. 

C. SUMMARY 

The AMCM community needs to implement the Cl Information System 
based on the architecture outlined throughout this thesis. With the appropriate 
networked architecture, the network can be expanded as the need arises. Without 
the appropriate architecture, the community will be locked into another closed 
stovepipe system tied to individual systems and components. 
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IX. DEMONSTRATION RESULTS 


A. INTRODUCTION 

Two laboratory proof-of-concept demonstrations were successfully 
conducted. The first demonstration was presented to Captain Arnold (AMCM 
PEO) on 16 September 1996 and the second demonstration was presented to 
Admiral Williams (PEO MIW) on 8 October 1996. 

B. DEMONSTRATION GOALS 

The demonstration goal was to provide a working proof-of-concept 
prototype using standard COTS/NDI equipment, NRaD’s Battle Force HF E-mail 
System, multicast backbone (MBone) video tools within an open architecture 
using standard protocols available today. [Ref 17] The demonstration was also 
intended to provide an overview of the capabilities inherent in the system’s 
architectural design. These capabilities include: 

• Near-real time video and message reports over LOS using UHF 
equipment 

• Single frame imagery and message reports OTH using HF equipment 

• Adjustable throughput, frame rate, and resolution of the multicast 
backbone video tools 

• Internet Protocol (IP) routing and internet compatible HF e-mail 

• Flexible, scalable, reliable, open network architecture 

The demonstration was an opportunity to provide a working systems-based 
solution to AMCM’s G^I problem. 
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C. DEMONSTRATION SETUP 


The demonstration was arranged using two LANs on two separate tables to 
simulate the MOC and a mobile MH-53E helicopter respectively as shown in 
Figure 9.1. Connectivity between the two LANs was only possible through UHF, 
HF and a microwave bridge RF based links. The "MOC" LAN was also connected 
via a standard 10Base2 Ethernet cable to the Naval Postgraduate School’s network 
backbone to demonstrate connectivity to the Internet. AN/AQS-14 sonar input 
was simulated using an actual sonar playback videotape provided by the Heli¬ 
copter Mine Countermeasures Squadron Fifteen. 

D. DEMONSTRATION RESULTS 

AN/AQS-14 sonar video was successfully converted from standard VHS 
video cassette format into IP datagrams and forwarded over a "MH-53E" LAN to 
the radio-based wireless WAN. It was then transmitted via the radio based WAN 
to the "MOC" LAN and forwarded to a processor where it was displayed on a 
monitor as a real-time sonar video stream. 

Single frame mine-like object images were captured using a "frame 
grabber" fi*om the sonar video data stream and forwarded over the RF network to 
the MOC LAN where they automatically appeared on the screen as clear single 
frame mine-like object images. 

NRaD’s Battle Force HF E-Mail was installed but a "clear to send modem 
error" precluded fully successful e-mail operations. The error was internal to the 
modem itself and was not a result of any architectural or system design flaws. 
NRaD’s Battle Force Electronic mail HF e-mail system has been proven to work 
and has successfully been demonstrated in shipboard environments. 
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Figure 9.1. MH-53E Aircraft 
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UHF throughput was demonstrated at 250 Kbps and at 380Kbps to show the 
frame rate that can be expected using UHF based WAN communications channels 
for video transmissions. 

Messages were transferred over the HF radio’s internal data link channel to 
demonstrate HF connectivity. 

The sonar video used in the lab demonstration was not integrated with 
aircraft skew, heading, altitude, time etc. as the sensors that provide these inputs 
were not available. Figure 9.2 shows the lab testbed component diagram. 

E. SUMMARY 

The demonstration design objectives were met as sonar video and single 
frame imagery information were successfully transferred in near-real time over the 
radio based WAN. Nearly any communications component, regardless of 
frequency (VHF, UHF, HF etc.) can be connected to a router, controlled, and be 
used to pass information over the radio-based WAN. This system was ready to be 
tested at sea. Planned testing was unexpectedly terminated when the author’s 
orders were changed just prior to graduation. 
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Figure 9.2. Lab Testbed Component Diagram 
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X. LESSONS LEARNED AND CONCLUSIONS 


A. INTRODUCTION 

This thesis was rapidly written after building the prototype system. As a 
result of building the prototype, numerous lessons have been learned first hand that 
would not have been as deeply gleaned from a purely academic endeavor. 

B. LESSONS LEARNED 

Proper network interfaces are essential. The system must be network¬ 
centric with common LAN interfaces. Serial connections between components 
severely limits flexibility and interoperability. If the components have common 
network interfaces, they can be attached to a network and information can be 
routed or shared between the components. 

Ethernet (IEEE802.3) and Internet Protocol (IP) compatible products are 
widespread. If a system component doesn’t provide the interface, chances are an 
internal or external adapter or card can be purchased COTS that will provide the 
appropriate interface. For example, Ethernet and FDDI cards are available for 
VME bus based systems. 

Use what is available and proven to work before attempting exotic capabil¬ 
ities. AX.25 and NRaD’s Battle Force HF E-Mail system is a good start. After 
successfully integrating this system, begin to add basic capabilities such as secure 
e-mail encryption tools and image compression. 

Battle Force TCP must be modified for use in wireless environments. 
Numerous modification schemes are available. The problem is well understood, 
having been solved both by the amateur radio community and by other parts of the 
Navy such as NRaD. NRaD’s Battle Force HF E-Mail system uses the JNOS 
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Implementation of TCP/IP over the AX.25 packet radio data link layer. Adequate 
performance is possible today nevertheless. 

Data packaging is a very important issue. The e-mail enveloping definition 
is the same independent of the contents inside. MIME is recommended as it has 
less overhead, is readily available, poses less development risk than X.400, and is 
the most compatible. 

Information systems architecture as outlined in Chapters II, III and IV needs 
to be corporately established throughout the MW community. This is not a 
programmatic function. Information systems architecture is not a platform issue, 
but rather a cross-platform one. A cadre of individuals must understand the 
information systems architecture in order to guide multiple programs in a coherent 
direction. 

Systems engineering is no longer a "do it once at program inception" affair. 
It must be viewed as life-cycle activity from the overall systems perspective. Such 
an approach was previously lacking for AMCM. This thesis provides the founda¬ 
tion for an overall system that can be planned on a life-cycle basis. 

C. CONCLUSIONS 

The transmission of sonar video itself is not a necessary requirement. The 
use of CAD on the MH-53E LAN will provide a near-real time over-the-horizon 
video processing capability, as the TARLOC position information and single 
frame mine-like contact imagery can be supported within HF transmission para¬ 
meters. 

Common data definitions are essential. Common data definitions save 
processing time by eliminating conversions and provide data interoperability 
between end systems which directly support rapid near-real time information 
exchanges between the sensor and the decision maker. 
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A good inherent design goal is to get information put into Internet Protocol 
(IP). Once information is converted into IP datagrams, it can be transported over 
networks virtually everywhere. 

D. SUMMARY 

Numerous lessons were learned during the building of the prototype. Most 
importantly, a network-centric, systems based, open architectural approach 
provides the highest levels of interoperability, availability and scalability. Other 
stovepipe proprietary solutions will continue to fail. 


83 



84 



LIST OF REFERENCES 


1. Naval Doctrine Publication (NDP) 6, Naval Command and Control. Naval 
Doctrine Command, Norfolk, VA, p. 24, 1995. 

2. Nemzow, M., Implementing Wireless Networks. McGraw-Hill, Inc., San 
Francisco, CA, 1995. 

3. RFC791, Request for Comments (RFC) are available on the Internet @http: 
//rs.intemic.net. 

4. RFC793, Request for Comments (RFC) are available on the Internet 
@http://rs.intemic.net. 

5. RFC821, Request for Comments (RFC) are available on the Internet 
@http://rs.intemic.net. 

6. RFC822, Request for Comments (RFC) are available on the Internet 
@http ://rs. intemic .net. 

7. Tannenbaum, A., Computer Networks. 3rd Edition, Prentice Hall PTR, 
Upper Saddle River, NJ, pp. 632, 643, 644, 646, 655,1996. 

8. RFC 1521, Request for Comments (RFC) are available on the Internet 
@http://rs.intemic.net. 

9. Ankney, Richard, "Introduction to Cryptographic Standards," http://www. 
itd.rtl.navy.mil/ITD.../cipher/cipher-crypto-stds.html. 

10. RFC 1448, Request for Comments (RFC) are available on the Internet 
@http ://rs. intemic.net. 

11. Hamming’s Learning to Learn, Lecture Notes, Lecture 28, "Systems 
Engineering," p. 5, 1994. 

12. MIW C'*I Requirements Document, COMINEWARCOM, Version 2.1, 
Corpus Christi, TX, p. 2, 1 June 1995. 


85 




13. Mine Warfare (MIW) C'^I Master Plan, Version 1.0, para 3.4.2.2, 3.9.3, 9 
August 1996. 

14. Mine Warfare (MIW) C^’ISR Operational Architecture, 1 June 1996. 

15. Mine Warfare (MIW) C'^ISR Systems Architecture (Top Level Engineering 
Design), Working Draft, 11 June 1996. 

16. Denny, Chris and John Bouma, "C'^I Architecture Currently Supporting the 
Mine Warfare Community," LANTFLT Systems Engineers. March 1996. 

17. Execution Plan, Appendix C, Configurations and Interface Descriptions for 
Demonstration I Joint Countermine (JCM) Advanced Concept Technical 
Demonstration (ACTD) Command, Control, Communications and Intelli¬ 
gence (C'^I) Component (draft), 28 March 1996. 

18. Mine Warfare Environmental Decision Aids Library (MEDAL) Program 
Plan Prepared by Loral Defense Systems, Reston, VA, May 1995. 

19. Battle Force Electronic Mail for Ft. Derrick Transportable System Manual. 
Naval Command, Control and Ocean Surveillance Center, RDT&E 
Division (NRaD), Terrestrial Link Implementation Branch, Code 846, 16 
August 1996. 

20. Macedonia, Michael R., and Donald P. Brutzman, "MBone Provides Audio 
and Video Across the Internet," IEEE Computer, Vol. 27, No. 4, pp. 30-36, 
4 April 1994. 


86 



INITIAL DISTRIBUTION LIST 


1. Defense Technical Information Center. 2 

8725 John J. Kingman Rd., STE 0944 

Fort Belvoir, VA 22060-6218 

2. Dudley Knox Library. 2 

Naval Postgraduate School 

411 Dyer Rd. 

Monterey, CA 93943-5101 

3. Program Executive Office Mine Warfare (PEO MIW) . 1 

2531 Jefferson Davis Highway 

Crystal Plaza 6, Room 920 
Arlington, VA 22242-5167 

4. Program Executive Office (PMS 210). 1 

2531 Jefferson Davis Highway 

Crystal Plaza 6, Room 936 
Arlington, VA 22242-5167 

5. Program Executive Office (PMS 407). 1 

2531 Jefferson Davis Highway 

Crystal Plaza 6 
Arlington, VA 22242-5167 

6. Chief of Naval Operations (CNO) . 1 

The Pentagon 

N852E AMCM Requirements Officer 
Washington, DC 20350-2000 

7. NAVSURFWARCEN Coastal Systems Station Panama City (CSS) .... 1 
Dahlgren Division 

Airborne Fleet Readiness Branch (Code 2220) 

Panama City, FL 32407-7001 


87 









8. Commander Mine Warfare Command (CMWC). 1 

325 5th Street 

Corpus Christi, TX 78419-5032 

9. Commanding Officer . 1 

Helicopter Mine Countermeasures Squadron Fifteen (HM-15) 

NAS Corpus Christi, TX 78419 

10. Commanding Officer . 1 

Helicopter Mine Countermeasures Squadron Fifteen (HM-14) 

SP-31 A Street 

NAS Norfolk, VA 23511-5700 

11. Naval Air Systems Command (NAVAIR). 1 

Jefferson Plaza Bldg 1 

1421 Jefferson Davis Highway 
Arlington, VA 22243-1000 

12. Naval Air Warfare Center Aircraft Division (NAWCAD). 1 

Combat Engineering and Integration Section 

Building 8225, Code 4.5.8.3.2 
St. Inigoes, MD 20684 

13. Commanding Officer . 1 

Attn: Mr. Gordon Shillito 

Operations Systems Center 
Martinsburg, VA 25401 

14. Commandant (G-OCC). 1 

Attn: Capt Richard Mead 

US Coast Guard 
Washington, DC 20593 

15. Commandant (G-SCT). 1 

Attn: Cdr Jim Bussey 

US Coast Guard 
Washington, DC 20593 


88 











16. Commandant (G-S). 1 

Attn; Cdr Jim Hall 

US Coast Guard 
Washington, DC 20593 

17. Commandant (G-SCE). 1 

Attn: Capt Martini 

US Coast Guard 
Washington, DC 20593 

18. Commanding Officer . 1 

Attn: Lt Joe Staier 

USCG C2Cen 
4000 Coast Guard Blvd. 

Portsmouth, VA 23703-2199 

19. Commanding Officer . 1 

Attn; Capt Paul Miller 

USCG C2Cen 
4000 Coast Guard Blvd. 

Portsmouth, VA 23703-2199 

20. Commanding Officer . 1 

Attn; Don Cundy 

USCG R&DCen 
Avery Point 
Groton, CT 06340 

21. David C. Carlton. 1 

Head, Applied Technology Branch, Code 745 

49590 Passing Road, Bldg 1 Room B307 
San Diego, CA 92152-5000 

22. Steve Haeger. 1 

Advanced Technology Staff 

Code TDT 

Stennis Space Center 

Bay St. Louis, MS 39520 


89 









23. Terry Danielson . 1 

Naval Command, Control and Ocean Surveillance Center, RDT&E 
Division (NRaD) 

Terrestrial Link Implementation Branch, Code 846 
San Diego, CA 92152-5000 

24. Richard S. Hillyer. 1 

Planning Systems, Inc. 

7923 Jones Branch Drive 
McLean, VA 22102 

25. Don Brutzman (Code UW/Br) . 2 

Naval Postgraduate School 

Monterey, CA 93943-5100 

26. Prof. Rex A. Buddenberg (Code SM/Bu). 10 

Naval Postgraduate School 

Monterey, CA 93943-5103 

27. Alan Beam . 1 

ARL/PSU 

P.O. Box 336 
Tracyton,WA 98393 

28. Prof. Dan C. Boger (CC) . 1 

Naval Postgraduate School 

Monterey, CA 93943-5100 

29. Prof Jim Eagle (Code UW) . 1 

Naval Postgraduate School 

Monterey, CA 93943-5100 

30. RADM Chuck Home, USN (Ret.). 1 

92 On the Harbor Drive 

Mt. Pleasant, SC 29464 


90 










31. ADM Thomas B. Hayward, USN (Ret.). 1 

TBH Associates 

100 Bishop St. 

P.O.Box 4150 
Honolulu, HI 96812-4150 

32. LT Steven M. Graves . 2 

5607 White Ave. 

Baltimore, MD 21206 


91 





